Fills the app's String Catalog (Localizable.xcstrings) with translations — the human translations we already have from GlotPress, plus machine translations for whatever is still untranslated. This gets the catalog ready ahead of moving the app over to String Catalogs. Nothing users see changes.

Two things to know

Staged, not shipped. The catalog file is generated, but the app doesn't read it at runtime yet — regular strings still come from the existing Localizable.strings. This only pre-fills the catalog for the eventual switch-over. Machine translations are marked needs_review, so they stay clearly separate from reviewed human translations and can sit in the catalog without shipping to anyone.

Manual, not automated. These lanes are run by hand, not wired into any release or CI step: a run extracts strings, calls a paid translation API, and commits a large file, so it shouldn't happen on its own. The unit tests still run in CI.

How it works

Three steps, each runnable on its own:

1. generate_strings_catalog — extracts the English strings from the code into the catalog.
2. download_catalog_strings — downloads the current translations from GlotPress.
3. localize_catalog — adds the human translations, machine-translates whatever's left, and commits.

Each string gets the best translation available in each language: a human translation if there is one, otherwise a machine translation, otherwise the English text. Human translations are marked translated; machine translations and English fallbacks are marked needs_review.

Re-running is cheap. A machine translation already in the catalog is left alone instead of being requested again, and a human translation always replaces a machine one on the next run. Machine translation only happens when an API key is set — without one, the catalog fills from human translations and English. A machine translation is kept only if its format placeholders (%1$@, %2$d, …) match the English, so a mangled one falls back to English rather than shipping a broken string.

Test plan

• Unit tests pass (fastlane/lanes/*_test.rb) — these run in CI
• rubocop clean
• Manual run against live GlotPress data (steps below)

Manual run

First bundle install. A machine-translation run also needs an ANTHROPIC_API_KEY — the Fastfile picks it up from ~/.wpios-env.default. Without a key the run still works: it fills in the human translations and English only, skips machine translation, and costs nothing — a good way to check the plumbing before spending anything.

Run the three lanes, scoped to one well-translated locale to keep it cheap:

bundle exec fastlane ios generate_strings_catalog
bundle exec fastlane ios download_catalog_strings locales:fr
bundle exec fastlane ios localize_catalog locales:fr

1. generate_strings_catalog extracts the English strings into Localizable.xcstrings (~3,900 of them). No network, no cost.
2. download_catalog_strings downloads the French translations from GlotPress into a scratch folder. No cost.
3. localize_catalog fills the French translations into the catalog, machine-translates the gaps, and commits.

French is well-translated, so most entries come from GlotPress and only a small number fall to machine translation, which keeps the cost for one locale low. A few entries may stay English where a machine translation was rejected for not matching the English placeholders.

localize_catalog prints a per-locale summary at the end, so you can check the result straight from the log — no need to open the catalog:

fr: 3923 entries — 3805 human, 112 machine, 6 still English
    editor.post.delete: "Delete" → "Supprimer"
    settings.title: "Settings" → "Réglages"

Expect mostly human, a smaller machine count, and only a few still English. The sample lines let you spot-check the machine translations for obvious nonsense.

localize_catalog commits the catalog, which is a large file. This run is only to check the output and cost, so discard the commit rather than pushing it (git reset --hard HEAD~1). The catalog gets committed for real during the migration, not in this PR.

Plurals are handled the same way in a separate PR (#25710), since they live in their own catalog file.